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(54) Abstract Title 

Mobile phone prepayment system 



(57) A system for the prepayment of credit into a mobile phone account comprises a point of sale (POS) 
terminal which may incorporate a card reader and is connected to a POS network. The system further includes 
means for forwarding a credit request message from the terminal to a transaction management system, and a 
mobile phone accounting system connected to the transaction management system. The accounting system is 
adapted to authorise requests processed by the transaction management system and to credit user accounts 
on receipt of a valid request, so that requests from the POS terminal are forwarded to the accounting system 
and, if valid, an authorisation is transmitted back to the terminal and the user account is updated. The mobile 
phone network then sends a message to the user's phone confirming that the account has been updated. 
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At least one drawing originally filed was informal and the print reproduced here is taken from a later filed formal copy. 

This print takes account of replacement documents submitted after the date of filing to enable the application to comply 
with the formal requirements of the Patents Rules 1995 
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Method and System for the Prepayment of a 
Mobile Telephone Account 

This invention relates to methods and systems for the 
prepayment of a mobile telephone account. 

At present, mobile telephone accounts can be 
conveniently divided into two groups f namely prepayment 
accounts and postpayment accounts- The latter are 
traditional accounts which are billed at regular 
intervals to customers in respect of the amount of 
telephone usage in the preceding billing period (and 
thus credit is extended to the customer) . Prepayment 
accounts differ in that the customer must buy credit in 
advance before the account has been used. 

A known method of administering a prepayment account is 
to sell cards which "carry" fixed amounts of credit and 
without which a particular mobile phone model is 
inoperable. The phone can be used until the remaining 
credit is exhausted, following which the phone requires 
a fresh card to operate on the network. 

This system is disadvantageous in that the customer is 
compelled to physically buy and install a credit- 
carrying card every time credit is exhausted. 

A further known prepayment system utilises credit card 
payments which are authorised by the customer 
telephoning the telephone company, requesting the 
purchase of credit (or "airtime"), and quoting credit 
card details. The telephone company employee then uses 



standard credit card authorisation procedures to charge 
the customer for the requested amount of airtime and 
credits the customer's account accordingly. Yet a 
further system allows a customer to use an ATM card to 
place funds in a mobile phone account from a bank 
account . 

Both of these systems are limited to customers who have 
credit card and banking facilities respectively. 

It is an object of the present invention to provide an 
improved system and method which allows for the 
prepayment of credit into a mobile phone account. 

The invention provides a system for the prepayment of 
credit into a mobile phone account comprising a point 
of sale (POS) terminal optionally incorporating a card 
reader and connected to a POS network, means for 
forwarding a credit request message from the terminal 
to a transaction management system, and a mobile phone 
accounting system connected to the transaction 
management system and adapted to authorise requests 
processed by the transaction management system and 
adapted to credit user accounts on receipt of a valid 
request, wherein requests from the POS terminal are 
forwarded to the accounting system and r if valid, an 
authorisation is transmitted back to the terminal and 
the user account is updated. 

Optionally, the mobile phone accounting system causes a 
message to be sent by the mobile phone network to the 
customer's phone confirming the updated account status, 
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so that a mobile phone which was inactive due to zero 
credit in the account is activated automatically. 
Preferably the card for use with the scheme is a 
loyalty card such as may be issued e.g. by a store or 
5 airline. In another aspect the card may be a bank or 
credit card. It may hold information on a magnetic 
strip or a microchip, for example. 

Brief description of drawings 

10 

Figure 1. Main components of Architecture 

Figure 2. Electronic POS interaction with Processing 
Centre, Side 1 of the architecture 

15 

Figure 3. Phone Company integration, Side 2 of the 
architecture 

In what follows, a typical system and method according 
20 to the invention will be described illustrating the use 
of a loyalty card for a store. In this scenario, the 
customer when paying a checkout bill requests the 
purchase of airtime. The operator swipes the card, 
enters the required value into the system, and receives 
25 payment from the customer (this payment is subsequently 
transferred from the store to the phone company) . 

The following description outlines the technical 
requirements to support an electronic payment system 
30 for loyalty card scheme members utilising prepaid 
mobile services on the mobile phone network 
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There are two distinct components to the supporting 
architecture. The first is the infrastructure that 
interacts with the retail Point of Sale (POS) devices 
located throughout all branches of the store operating 
5 the loyalty card scheme. This part of the 

infrastructure will utilise standards and components 
normally found in a POS type application (e.g. credit 
card authorisation) . 

10 The other significant part of the infrastructure will 
integrate with the mobile network's internal prepayment 
systems. The specific interface to be used will depend 
on the technical architecture of the deployed 
prepayment system used by the mobile phone company, 

15 

The main components of this system are outlined in 
Figure 1. The design and development of this 
infrastructure requires the integration of a number of 
20 different systems and components. All of the systems 
used for in this architecture are in use in other 
applications today. The following are highlights of the 
architecture: 

25 • Existing links between the store and the Banks 
remains unchanged 

• The store's POS devices require application changes 
which will be facilitated by the Banks acting under 

30 instruction from the store. 

• All loyalty card transactions involving prepaid 
airtime will be sent real-time to the Processing 



5 

Centre, which will immediately communicate with the 
phone company's prepaid system. 

• The communications architecture and message flow . 

5 between each store outlet and the processing centre 
will be based on the APACS-30 standards. 

• The communications architecture and message flow 
between the processing centre and the phone company 

10 are dictated by whatever open Application Programming 
Interfaces (API's) or similar facilities are employed 
in the phone company's system. 

15 Figure 2 outlines the major components supporting the 
integration between each store outlet and the 
Processing Centre. Preferably, major components 
outlined within the Processing Centre will all be based 
on a product called Base-24 supplied by ACI. This 

20 software product is used by most financial institutions 
world-wide to manage real-time transactions with POS 
and Automated Teller Machine (ATM) devices. The phone 
company's Transaction Manager component will depend on 
the links available within the particular system used. 

25 

The following is a summary of the functions performed 
by each component: 

APACS-30 

30 All communications with POS devices and servers will be 
facilitated by this component. It is responsible for 
supplying and receiving APACS-30 formatted messages. 
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EPS Transaction Manager 

This is the main processing engine within the centre. 
It receives and communicates with APACS-30 regarding 
customer prepayments at the POS. It also communicates 
5 with the phone company's Transaction Manager to provide 
updated account balance information. Finally, it 
interacts with the settlement system for provision of 
settlement information . 

10 Settlement Manager 

All transactions are monitored and recorded within the 
Settlement Management System. It provides full 
accounting information to facilitate the settlement of 
cash transactions that have taken place between the 
15 phone company's customers and the store branches. 

Phone company' s Transaction Manager 

This system is responsible for all communications with 
the mobile phone network. 

20 

Figure 3 outlines the major components involved in the 
interaction between the phone company network and the 
Processing Centre. In most cases the best architecture 
for the integration of the Transaction Manager may be 
25 to utilise the Interactive Voice Response (IVR) 

procedures which are normally used with token based 
prepaid systems of this nature. 

Functionally, the Electronic Payment System is similar 
30 to the token based (scratchcard) system at the account 
authorisation level. While the origin of the account 
update request is different (IVR call-script 
interaction vs. card-swipe device), the requirement to 
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successfully update the account and notify the customer 
is identical. 

The following is a diagrammatic description of the 
5 message flow between the point of sale terminal (via 
server or direct) and the Processing Centre. 

The message transactions described below will be 
encoded and exchanged as per the APACS-30 specification 

10 Appendix L (Message Protocols and Formats for Credit 
Authorisation Transactions) . In the following message 
descriptions, the first field is for design purposes 
only and will not appear in the transaction flow. The 
naming convention is TRM=Terrninal, HST=Host followed by 

15 a unique number (e.g. TRM-01 is the message number one, 
generated by a terminal) . 



Message TRM-01 




Message ID 




Type 



CARD NUM 



Dunnes Value Card Number 



£VALUE 



Value of airtime required 
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Message TRM-02 



TRM-02 



REFUND-REQ 



CARD NUM 



£VALUE 



Message ID 



Type 



Dunnes Value Card Number 



Value of airtime refund 



5 Message HST-01 



HST-0 1 Message ID 

AUTH-RESP~ Type 
RESP-CODE App specific code 

AUTH- C ODE Same format M for cc 



Exception Handling 

There are a number of exceptions to the normal 
transaction flow that must be catered for. The 
following list attempts to identify all of the possible 
exceptions that may occur and the strategy for dealing 
with them. 

Exception 1 - Communications Link Failure 

There are two types of failure here. Firstly (Type 1), 
the in-store network could fail, disabling the POS from 
communicating with the in-store server. This failure 
would cause all credit/debit, as well as this value 
card application to fail. Solutions are based in many 
cases on the existing process for handling such errors. 

Secondly (Type 2), the in-store controller may fail to 
make a connection to the remote host. This causes other 
applications (e.g. credit card authorisations) to batch 
up the individual requests. Again, solutions are based 
on the recognised methods of handling such failures. 

Exception 2 - Operator Entered Incorrect Amount 

Unless the customer spots this on reading his receipt 
(or on seeing the operator input the incorrect amount), 
this will only become apparent to the customer at some 
later time. This can therefore be dealt with at the 
Customer Care Centre. 

Exception 3 - Card Details are Keyed in Incorrectly 

The process for handling this is similar to Exception 
2. If spotted by the customer, it can be rectified 
there and then (refund req for the incorrect number, 
followed by auth req for the correct number) . 
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Otherwise, it can be dealt with at the Customer Care 
Centre . 

Exception 4 - Auth Req amount is below Minimum 
5 Transaction Amount (MTA) 

A minimum transaction amount will be required by this 
service. However it is decided to deal with this 
exception, one must ensure that the limit can be easily 
changed. The result at the till will be a special 
10 "decline" message. This exception will be close to zero 
with good information to till operators and 
infrequently changing MTA. 

Exception 5 - Operator completed Transaction before 
15 Payment and Payment failed 

If the transaction for airtime has been completed 
before payment and payment cannot be made (for whatever 
reason) , then is will be up to the operator to initiate 
a Refund-Req, which will back out the transaction at 
20 the host. 

Exception 6 - Operator initiates transaction with all 
details, Terminal fails (power failure, etc.) 

This is handled in the same way as with the existing 
25 loyalty card transactions. 

Exception 7 - Customer presents incorrect card (valid 
for this transaction, but not his card) . 

The outcome of a successful transaction always results 
30 in a predefined valuecard customers mobile account 
being credited with a specified sum. There is no 
possibility of the card being used to credit a 



DIFFERENT mobile account. If the card presented is that 
of the customers spouse or other relations, it will not 
be spotted until after the transaction and it will then 
be dealt with by the Customer Care Centre. 

If the card has been reported stolen, one will suitably 
follow the same procedures for stolen credit cards, 
even though there is no possibility of the thief 
abusing the account. (In fact the only "damage" the 
thief can do is to credit the victim's account). 

Exception 8 - Abuse of Refund Request 

The rules for refunds are as follows: 

1- At the point of sale, refunds can only be given 
against the specific card that was credited at the 
specific point of sale within the last 10 minutes. (Ail 
APACS-30 messages received by the Processing Centre 
host will be time stamped.). If the time limit has 
expired (for whatever reason), the customer will be 
referred to the Customer Care Centre and asked to keep 
his original receipt. 

2 - The amount of the refund must be less than or equal 
to the originally credited amount. 

3 - Refunds can only be given. under one of the 
following circumstances: a) customer believes the 
operator entered the incorrect amount (e.g. "I asked 
for £20 not £25"), or b> as a result of Exception 5, 
above . 



Under either type of communications failure described 
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in Exception 1, above, the customer will be referred to 
the Customer Care Centre. No automatic refund can be 
facilitated at the till. 

5 All other refund issues will be dealt with at the 
Customer Care Centre. 

Terminal Display and Printing Receipts 

The receipt printed for the customer will be similar to 
10 that printed for a credit card customer. Important 
information that will be contained on the receipt: 

1 - Authorisation Code 

2 - Transaction Date and Time 

15 3 - Store identification (and POS, if possible) 

4 - (possible short text message - "please keep you 
receipt as proof of payment. This is also your VAT 
receipt") 

20 No special terminal (LCD/LED) displays are envisioned 
at this time. 

General Notes 

The design of this application is such that a special 
25 key sequence be entered by the till operator before the 
card is wiped. This should be designed so that it is a 
1 or 2 key sequence and that the same key descriptors 
are used across multiple vendors terminals. There 
should also be a cancel key identified. 

30 

To handle Exception 1 (Comms failure), the in-store 
server will be required to keep a list of valid account 
numbers. In Comms-Link-Down mode, the server will 
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provide the Auth-Response only for those cards which 
appear on the list. The server will decline ALL refund 
requests in this mode. 

5 Summary 

The software components that are used in this 
architecture are in use in other applications today 
(mainly within the financial services industry) . The 
technical changes, scale and scope of the work required 

10 to develop the Processing Centre and the integration of 
the Processing Centre with each store outlet is well 
understood today and the proposed transaction flow and 
exception handling is merely exemplary of a single 
system, which can be modified to suit individual 

15 circumstances. 

Although discussed in particular in relation to a store 
loyalty card, other cards can be used, as appropriate. 



Claims : 



1- A system for the prepayment of credit into a 

mobile phone account comprising a point of sale (POS) 
terminal optionally incorporating a card reader and 
connected to a POS network, means for forwarding a 
credit request message from the terminal to a 
transaction management system, and a mobile phone 
accounting system connected to the transaction 
management system and adapted to authorise requests 
processed by the transaction management system and 
adapted to credit user accounts on receipt of a valid 
request, wherein requests from the POS terminal are 
forwarded to the accounting system and, if valid, an 
authorisation is transmitted back to the terminal and 
the user account is updated. 

2. A system according to Claim 1, wherein the 

mobile phone accounting system comprises means for 
sending a message by the mobile phone network to the 
mobile phone corresponding to said user account 
confirming the updated account status, whereby a mobile 
phone which was inactive due to zero credit in the 
account is activated automatically. 

3- A system according to Claim 1 or 2, wherein the 
card for use with the POS card reader is a loyalty card 
such as a store or airline loyalty card. 

4- A system for the prepayment of credit into a 
mobile phone account, substantially as hereinbefore 
described with reference to Figs. 1-3 of the 
accompanying Drawings . 
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